
Nous souhaitons que notre analyse de régression atteigne une couverture de test maximale et soit largement automatisée. La réalité est souvent bien différente : des milliers de cas de test manuels dans l’ensemble de régression, dont vous êtes certain qu’au moins 25 % sont inutiles – mais lesquels ? Pourquoi tant de tests se sont-ils accumulés ? À l’aide d’un exemple concret, nous allons illustrer quels cas de test sont pertinents et lesquels ne le sont pas. Une sélection judicieuse est essentielle pour un ensemble de régression propre et efficace.
Cet exemple pratique convient également aux formateurs spécialisés ayant peu d'expérience en matière de tests.
Une entreprise a lancé un projet de numérisation. L'objectif est de créer une application pour les clients permettant d'effectuer les tâches suivantes :
Il convient également de noter les détails suivants :
Les deux premiers niveaux de test, les tests unitaires et les tests d'intégration, sont généralement effectués par les développeurs ou les testeurs techniques. Ces tests évaluent la fonctionnalité des modules et l'interaction des composants interdépendants. Les tests système, quant à eux, vérifient la conformité aux spécifications lorsque le système complet est disponible. Il est crucial que les tests système présentent une couverture afin d'identifier les erreurs logicielles avant la mise en production. Des tests système courts facilitent l'identification et la localisation des erreurs potentielles. Les tests système suivants conviendraient à la spécification mentionnée ci-dessus :
Une fois le logiciel mis en production, les tests système sont convertis en tests de régression. Le nombre de cas de test pour la régression doit être considérablement réduit. L'objectif de la régression est d'identifier les effets indésirables des modifications logicielles. Il ne s'agit pas de retester l'intégralité dulogiciel. Ceci est également valable si l'automatisation des tests est prévue, car même les tests automatisés nécessitent une maintenance régulière et ne sont donc pas « gratuits » à exécuter. Les tests de régression se concentrent sur l'essentiel. Combiner plusieurs tests système peut également s'avérer avantageux pour gagner du temps d'exécution. La densité d'erreurs dans les tests de régression est généralement bien inférieure à celle des tests système. Nous avons sélectionné les tests système les plus importants et les avons combinés lorsque cela était pertinent. Ceci donne l'ensemble de tests de régression suivant :
Que se passe-t-il si l'application est développée davantage dans une version ultérieure ? L'ensemble de tests de régression nécessite une maintenance régulière. Nous supposons que la spécification sera étendue pour inclure le point suivant :
Cela engendre plusieurs tests système supplémentaires, que nous ne détaillerons pas ici. Plutôt que d'augmenter le nombre de tests de régression après la publication, le jeu de tests existant peut être adapté pour inclure également la vérification future des adresses :
Il est également possible que des cas de test soient supprimés de l'ensemble de régression après une modification logicielle s'ils ne sont plus pertinents en raison de cette modification (exemple : si les modifications d'adresse ne sont possibles que via l'application, il n'est plus nécessaire de réaliser des tests pour vérifier cela via le site web).
À quoi ressemble votre ensemble de régression ? Si vous souhaitez une consultation, n’hésitez pas à nous .
Souhaiteriez-vous bénéficier de notre expertise et mettre en œuvre des innovations technologiques ?


Vous avez une question ou souhaitez obtenir plus d'informations ? Laissez-nous vos coordonnées et nous vous rappellerons.